Те из вас, кто пользуется услугами облачного IaaS-хостинга Amazon AWS, наверняка знают, что у этого сервис-провайдера есть решение Storage Gateway, позволяющее организовать гибридную модель хранения данных предприятия, а именно - частично или полностью хранить данные инфраструктуры виртуальных машин VMware vSphere в облачном хранилище Amazon S3.

Теперь же решение Storage Gateway поддерживает не только гипервизор VMware ESXi, но и хранилища платформы Microsoft Hyper-V.

Storage Gateway представляет собой виртуальный модуль (Virtual Appliance), размещенный в виде ВМ на хостах ESXi или Hyper-V, который предоставляет стандартный интерфейс iSCSI и выступает в качестве таргета для хост-серверов с виртуальными машинами (в общем случае поддерживается доступ различных приложений). Работа Storage Gateway возможна в двух режимах:

• Gateway-Cached Volume — в рамках этой архитектуры вы создаете тома для виртуальных хранилищ и монтируете их как iSCSI-устройства для хост-серверов. Виртуальный модуль кэширует данные и сохраняет их в облаке Amazon S3, при этом в инфраструктуре заказчика хранятся только кэшированные данные, которые наиболее часто оказываются востребованными.
• Gateway-Stored Volume — в такой архитектуре все данные виртуальных машин хранятся локально, в рамках инфраструктуры заказчика, а Storage Gateway периодически создает снапшоты (инкрементально) и передает данные отличий от базового образа в облако Amazon S3. Это создает хорошие возможности для сценариев Disaster Recovery.

Storage Gateway передает данные в S3 через защищённый SSL-канал. Более подробно с технической точки зрения о решении можно узнать тут и тут.

С началом поддержки Hyper-V в Storage Gateway компания Amazon вступает в прямую конкуренцию с Microsoft, которая в прошлом году приобрела компанию StorSimple, занимавшуюся тем же самым (только у них это программно-аппаратный комплекс) - предоставлением облачных хранилищ через онпремизные сервисы, размещенные на площадке заказчика (cloud-integrated storage).

Стоимость сервисов Amazon Storage Gateway можно узнать на этой странице.

Компания StarWind Software, производитель средства номер 1 для создания отказоустойчивых хранилищ iSCSI для виртуальных машин VMware и Microsoft, выпустила интересный документ "HA Maintenance and Configuration Changes". В нем можно почитать о том, как необходимо производить обслуживание узлов StarWind iSCSI SAN, а также как правильно выполнять настройку узлов в отказоустойчивой конфигурации.

Документ будет полезен не только администраторам хранилищ StarWind, но и всем тем, кому интересно, как функционирует отказоустойчивое хранилище, как синхронизируются узлы, и как необходимо их обслуживать.

Операции, описанные в документе:

• замена узла-партнера, на который идет синхронная репликация данных
• ручная синхронизация узлов
• подготовка HA-устройства к обслуживанию и простою
• восстановление работоспособности узла после запланированного простоя
• изменение каналов синхронизации и сигналов доступности (heartbeats)
• настройка CHAP-аутентификации для HA-устройства

Документ "HA Maintenance and Configuration Changes" компании StarWind можно скачать по этой ссылке.

Как мы уже писали, в третьем квартале 2013 года компания Veeam Software представит новую версию своего решения для резервного копирования и репликации Veeam Backup and Replication 7. Мы уже рассказали о поддержке продуктом Veeam решения для управления облачной инфраструктурой VMware vCloud Director, о плагине для тонкого клиента vSphere Web Client и о восстановлении объектов Microsoft SharePoint.

Но следующая возможность порадует всех тех, кто с нетерпением ждал от Veeam поддержки резервного копирования на ленточные библиотеки, которые все еще остаются весьма распространенным техническим средством в Enterprise-инфраструктурах:

Если некоторые думают, что ленточные приводы для бэкапов уже не используются, то стоит поспрашивать коллег из крупных компаний, таких как РЖД или Газпром. Ленты живут и будут там жить еще долго, в том числе и потому, что они позволяют хранить резервные копии в географически удаленном от основного датацентра месте (на случай катастрофы).

Veeam Backup and Replication 7 будет поддерживать виртуальные ленточные библитеки (virtual tape library, VTL), физические ленточные библиотеки (tape libraries) и отдельные приводы (standalone drives).

Возможность Backup to tape позволяет осуществлять резервное копирование виртуальных машин на ленточные приводы (в рамках одной или нескольких задач), а также позволяет архивировать весь репозиторий Veeam Backup and Replication 7 на ленты.

Кроме этого, новая версия Veeam Backup and Replication 7 имеет возможность Files to tape, которая позволяет производить резервное копирование отдельных файлов ОС Windows или Linux на ленты. Важно, что для этой возможности поддерживаются не только виртуальные, но и физические серверы. При этом такой тип резервного копирования поддерживает механизм Microsoft VSS для создания консистентных бэкапов.

Интересно, что бесплатный продукт Veeam Backup Free Edition будет поддерживать возможность Files to tape, а также восстановление файлов, резервные копии которых сделаны с помощью встроенного средства Windows NTBackup.

Функция Restoring backups from tape позволяет восстановить с ленточных носителей резервные копии виртуальных машин на один из репозиториев Veeam, после чего станут доступны к использованию возможности Instant VM Recovery, Veeam Explorer for Microsoft Exchange и все другие Enterprise-фичи Veeam.

Помимо восстановления виртуальных машин целиком, есть, конечно же, и восстановление отдельных файлов с лент - Restoring files from tape. Выбираете целевую папку на физической или виртуальной машине и восстанавливаете туда необходимые файлы с ленточных приводов. Вот так, дождались - и это хорошо. Скоро не будет необходимости использовать Veeam для резервного копирования ВМ на дисковые устройства, а затем сторонний софт для сброса резервных копий на ленточные приводы. Теперь можно будет обходиться только решением Veeam Backup and Replication 7.

Кроме того, мы не упоминали о еще одной возможности Veeam Backup and Replication 7 - Virtual Lab for Hyper-V. Напомним, что еще в версии Veeam Backup and Relication 6.1 появилась поддержка технологии vPower для инфраструктуры резервного копирования виртуальных машин на платформе Hyper-V. Это касается и техники Instant VM Recovery - мгновенного восстановления ВМ за счет ее запуска напрямую из резервной копии.

Теперь же для инфраструктуры Hyper-V появилась поддержка виртуальных лабораторий по запросу (On-Demand Sandbox), которые для VMware vSphere были доступны еще в пятой версии продукта.

С помощью техник мгновенного запуска резервных копий администратор может запустить набор приложений в виртуальных машинах, являющихся изолированными копиями машин производственной среды, и проводить там какие угодно тесты. Для тестовой лаборатории задается хост Hyper-V, где это будет происходить, Datastore, Proxy Appliance для доступа Veeam Backup к тестовой лаборатории с виртуальными машинами в изолированной сети и настройки этой самой сети.

Более детально о возможности Virtual Lab for Hyper-V можно почитать вот в этом посте.

Эта статья приведена здесь на случай, если у вас появится необходимость подключить том VMFS к Windows-системе в режиме Read Only, чтобы скопировать его виртуальные машины, а далее заглянуть в содержимое их файлов виртуальных дисков (VMDK). Это может потребоваться в различных ситуациях (например, вы - злодей) и возможно средствами драйвера Open Source VMFS Driver от fluid Ops.

Компания StarWind Software, выпускающая лучший продукт для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, просит уважаемых читателей проголосовать за решения StarWind в номинации "Storage Virtualisation Product of the Year" на сайте Storage Awards 2013.

Если вам нравятся продукты наших коллег из Киева - не ленитесь, голосуйте за StarWind.

Многим из вас знакомы продукты StarWind iSCSI SAN и StarWind Native SAN for Hyper-V, предназначенные для создания отказоустойчивых хранилищ виртуальных машин для платформ VMware и Hyper-V.

Завтра компания StarWind Software проводит бесплатный вебинар "Simplifying Shared Storage for Hyper-V Environments", посвященный построению отказоустойчивых кластерных хранилищ на платформе Microsoft Hyper-V.

На вебинаре будет рассказано о решении StarWind Native SAN for Hyper-V, которое позволяет построить полнофункциональный отказоустойчивый кластер хранилищ из двух или трех серверов Microsoft Hyper-V на основе протокола iSCSI, без необходимости вложений в дорогостоящие СХД.

Вебинар проводит Макс Крафт - интересный рассказчик и мощнейший знаток решений StarWind.

Зарегистрироваться.

Компания StarWind Software, выпускающая лучший продукт для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, просит уважаемых читателей проголосовать за решения StarWind в номинации "Virtualisation Product of the Year".

Наши коллеги уже пробились в финал, обогнав множество сильных конкурентов. Поддержите их!

Компания StarWind Software, выпускающая продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, приглашает на бесплатный вебинар "Making Effective Use of Storage Virtualization", посвященный технологиям организации эффективных хранилищ для виртуализации VMware и Microsoft.

Мероприятие пройдет завтра, 27 марта в 16-00 по московскому времени.

На вебинаре будут рассмотрены следующие вопросы:

• Как увеличить аптайм хранилищ
• Как улучшить их производительность
• Как развернуть StarWind за 30 минут
• Стоимость решения

Зарегистрироваться на вебинар можно по этой ссылке.

Многие из вас, кто использует кластеризацию MSCS в виртуальных машинах на платформе VMware vSphere, возможно, замечали, что когда используется кластер Across Boxes (т.е. между ВМ на разных хостах), то перезагрузка хоста VMware ESXi занимает весьма продолжительное время (иногда - до получаса).

При этом на экране консоли написано:

Loading module multiextent.

В логе VMkernel можно увидеть следующее:

Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:01:57.828 cpu0:4096)WARNING: ScsiCore: 1353:Power-on Reset occurred on naa.6006016045502500176a24d34fbbdf11
Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:01:57.830 cpu0:4096)VMNIX: VmkDev: 2122: Added SCSI device vml0:3:0 (naa.6006016045502500166a24d34fbbdf11)
Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:02:37.842 cpu3:4099)ScsiDeviceIO: 1672:Command 0x1a to device "naa.6006016045502500176a24d34fbbdf11" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0

Дело здесь в том, что поскольку узлы кластера виртуальных машин используют диск RDM, который напрямую пробрасывается в виртуальную машину и для него используются SCSI reservations, то хост ESXi тратит много времени на обнаружение параметров устройства.

Избежать этого очень просто. Для этого:

• В ESX / ESXi 4.0 нужно выставить минимальное значение на число повторов операций при обнаружении конфликтов SCSI-резерваций (в Advanced Settings хостов):

Scsi.UWConflictRetries = 80

• Для ESXi 4.1 появилась дополнительная опция, которая уменьшает таймаут при загрузке в случае обнаружения конфликта. Это значение необходимо выставить в:

Scsi.CRTimeoutDuringBoot = 1

• Начиная с ESXi 5.0, опция Scsi.CRTimeoutDuringBoot больше не действует. Теперь нужно использовать команды множества esxcli storage. Для этого:

Сначала надо найти NAA-идентификатор устройства (физического LUN, на котором используется RDM). Для этого нужно зайти в управление путями до устройства (Manage Paths) и посмотреть на строчку, начинающуюся с naa...... - это и есть naa id.

Далее в консоли сервера ESXi нужно выполнить следующую команду (она пометит LUN как изначально зарезервированный):

esxcli storage core device setconfig -d naa.id --perennially-reserved=true

После этого хост ESXi, где были проведены данные манипуляции, будет загружаться быстро.

Более подробно о данной проблеме рассказано в KB 1016106.

Компания StarWind Software, выпускающая продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN & NAS 6.0, прошла сертификацию Microsoft по программе совместимости с Windows Server 2012. Это означает, что данное решение полностью соответствует всем техническим требованиям ОС от Microsoft и может быть использовано в производственной среде.

В итоге продукт StarWind iSCSI SAN & NAS находится в официальном списке Microsoft Windows Server Catalog:

Более подробно о продукте StarWind iSCSI SAN & NAS можно узнать по этой ссылке.

Компания StarWind Software, выпускающая продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, приглашает на бесплатный вебинар "Ultimate Data Protection for Virtualized Environments", посвященный продуктам семейства StarWind Backup Plug-in, позволяющим осуществлять резервное копирование виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V.

Вебинар проводит наш с вами киевский коллега Анатолий Вильчинский:

Мероприятие пройдет завтра, 13 марта в 16-00 по московскому времени. Участие бесплатное.

Зарегистрироваться.

Ну и напомним, что до конца марта действует скидка 25% на StarWind Backup Plug-in для VMware и Hyper-V.

Многим из вас знакомы продукты StarWind iSCSI SAN и StarWind Native SAN for Hyper-V, предназначенные для создания отказоустойчивых хранилищ виртуальных машин для платформ VMware и Hyper-V.

Начиная с 1-го марта и до 31-го компания StarWind Software дает скидку на продукты, начав со скидки 31% и уменьшая ее каждый день на 1%.

Сегодня скидка равна 28%:

Торопитесь, пока скидки еще есть. Заказать со скидкой продукт StarWind iSCSI SAN можно по этой ссылке, а продукт StarWind Native SAN for Hyper-V по этой.

Не так давно мы писали про средства резервного копирования и восстановления StarWind Hyper-V Backup Plug-in (опция к StarWind Native SAN) и  StarWind VMware Backup Plug-in (опция к StarWind iSCSI SAN), предназначенные для резервного копирования виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V.

Недавно компания StarWind объявила о запуске новой промо-акции: скидка 25% на StarWind Backup Plug-in для VMware и Hyper-V до конца 31 марта.

Квоту по обозначенным выше продуктам со скидкой можно запросить по этой ссылке.

Компания VMware выпустила интересный и полезный документ "Best Practices for Running VMware vSphere on Network-Attached Storage (NAS)", в котором описаны лучшие практики по работе платформы VMware vSphere на IP-хранилищах NAS/NFS, а также рекомендации по их развертыванию.

В документе рассмотрены различные варианты подключения дисковых массивов NFS, их преимущества и недостатки, а также совместная работа с такими технологиями как Storage I/O Control, VAAI, Network I/O Control, Storage DRS и прочими. Также администраторам будет интересно прочитать про расширенные настройки VMware vSphere, относящиеся к хранилищам NFS.

Компания StarWind Software, производитель средства номер 1 для создания отказоустойчивых хранилищ iSCSI для виртуальных машин VMware и Microsoft, выпустила интересный документ "StarWind High Availability Best Practices", где описаны лучшие практики для механизмов отказоустойчивости, имеющихся в продукте:

Данный документ подойдет как новичкам, так и опытным администраторам СХД StarWInd, поскольку в нем имеется описание необходимых настроек ОС, сетевого взаимодействия, тиминга адаптеров, канала синхронизации, а также имеются рекомендации по настройке HA-устройств, снабженные иллюстрациями.

На прошлой неделе компания Veeam Software в очередной раз доказала, что является действительно инновационной компанией, которая выпускает продукты с возможностями, отсутствующими у других производителей программного обеспечения для платформ виртуализации.

На этот раз компания выпустила решение для резервного копирования виртуальных машин VMware и Microsoft в облако - Veeam Backup & Replication Cloud Edition.

Многие из вас знают продукты StarWind iSCSI SAN и StarWind Native SAN for Hyper-V, предназначенные для создания отказоустойчивых хранилищ виртуальных машин для платформ VMware и Hyper-V. Но немногие знают что компания выпускает целых 3 SDK, которые могут помочь разработчикам интегрировать сторонние решения с продуктами StarWind.

Вот эти пакеты:

StarWind iSCSI SAN SDK

Это основной SDK, позволяющий использовать функциональность продуктов StarWind. С его помощью можно:

• Добавлять функции iSCSI Target в собственные приложения.
• Реализовать базовые типы устройств (ImageFile-based virtual disk, virtual DVD, RAM-based virtual disk, bridge to physical devices)
• Разрабатывать собственные SCSI-устройства с нужной функциональностью
• Соединять физические устройства с удаленными машинами (SPTI)

Более подробно о StarWind iSCSI SAN SDK можно почитать тут.

Как понятно из названия, этот SDK позволяет использовать механизмы дедупликации StarWind. Это технология in-line дедупликации данных (то есть во время резервного копирования, а не после) на уровне блоков, которая уже надежно зарекомендовала себя в продуктах StarWind. Она позволяет добиться коэффициента дедупликации данных до 20 к 1, использует регулируемый размер блока (под разные задачи хранилищ) и позволяет использовать кэширование на SSD-накопителях и в оперативной памяти.Об этом средстве мы уже упоминали вот тут.

SDK включает в себя библиотеку кода, примеры использования и документацию по API. Более подробно о StarWind Deduplication SDK можно почитать тут.

LSFS - это файловая система, предназначенная для хранения нескольких файлов виртуальных устройств (в первую очередь, устройств - образов виртуальных дисков), которая оптимизирована для высокой производительности при нагрузках типа "random access" (что характерно как раз для виртуальных машин).

StarWind LSFS SDK предоставляет:

• Слой хранения файлов, которые поддерживает высокую скорость ввода-вывода при случайной записи
• Технологию снапшотов
• Технологию Thin Provisioning для экономии дискового пространства хранилищ
• Технологию дедупликации

Более подробно о StarWind LSFS SDK можно почитать тут.

Интересная статья обнаружилась у Кормака, касающаяся того, как работает LUN Discovery на хостах VMware ESXi. Оказывается все новые LUN, висящие на одном таргете обнаруживаются сервером ESXi автоматически по заданному таймауту.

То есть мы сначала делаем Rescan, чтобы добавить новый таргет (порт массива), например, T2 с LUN ID=10:

Дальше на этом таргете создаем новый LUN ID=20, и через какое-то время он автоматически появляется в списках устройств:

Все это потому, что по умолчанию каждые 5 минут вызывается проба (SCSI-команды  REPORT_LUN и/или INQUIRY), целью которой является обнаружение новых устройств и путей на известных хосту таргетах. Настраивается это время (в секундах) в следующей расширенной настройке (по умолчанию 300 секунд):

Disk.DeviceReclaimTime

Кроме того, все это отрабатывает и тогда, когда происходят операции добавления (Rescan) или удаления таргета.

Какое-то время назад мы уже было подумали, что компания Parallels забила на виртуализацию серверов, продолжая продвигать контейнерную виртуализацию на базе технологии Virtuozzo. Ан, нет. На проходившем с 4 по 7 февраля Parallels Summit компания Parallels представила обновленные продукты Parallels Cloud Server и Parallels Cloud Storage.

В решении Cloud Server сочетается контейнерная виртуализация и виртуализация серверов (Parallels Containers и Parallels Hypervisor), а Cloud Storage - это облачное хранилище данных от Parallels, которое развертывается в инфраструктуре предприятия:

С помощью Parallels Cloud Storage сервис-провайдеры могут создать отказоустойчивый распределенный кластер для хранения данных на базе локальных дисков серверов (т.е. без SAN-инфраструктуры), в том числе и для виртуальных машин. Parallels Cloud Storage создает заданное количество копий на разных компьютерах и таким образом предотвращает потерю данных в случа сбоя одного из них (каждая дополнительная копия данных снижает скорость записи примерно на 10%, но улучшает чтение). Для большей надежности в Parallels Cloud Storage можно настроить использование контрольных сумм пользовательских данных и их проверку как при непосредственном доступе к данным, так и на регулярной основе.

Ну а продукт Parallels Cloud Server позволяет хранить и запускать виртуальные машины и контейнеры Parallels, выполнять горячую миграцию виртуальных серверов, а также расширять объем доступного пространства, не ограничиваясь объемом свободного места на локальном диске (т.е. подключать дисковые ресурсы пула Cloud Storage). Основной целевой аудиторией Parallels Cloud Server являются хостинг-провайдеры, которые расширяют перечень своих услуг, например до IaaS->PaaS->SaaS.

Интересной особенностью продукта Parallels Cloud Server является возможность развернуть виртуальные машины и контейнеры на одном физическом сервере. Также повысились возможности масштабируемости инфраструктуры Parallels - одной виртуальной машине можно назначить до 32 ядер процессора, 128 ГБ оперативной памяти и 5 ТБ дискового пространства. Кроме того, Parallels Cloud Server поддерживает до 1 ПБ доступного дискового пространства.

Запросить пробную версию Parallels Cloud Server можно на этой странице.

Если вам по каким-либо причинам понадобилось подключить флэшку или другое USB-устройство к VMware ESXi, например, в целях сбора диагностических данных или интеграции сторонних пакетов (или драйверов) в гипервизор, то сделать это можно способом, описанным ниже. Прежде всего отметим, что монтирование USB-хранилищ в консоль ESXi поддерживается только для файловой системы FAT16.

1. Сначала нужно отключить службу USB Arbitrator service, которая отвечает за проброс USB-девайсов в виртуальные машины хост-сервера. Для этого выполняем команду:

# /etc/init.d/usbarbitrator stop

2. Далее подключаем носитель к ESXi и проверяем девайс командой:

# esxcli storage core device list | grep -i usb

или смотрим список смонтированных файловых систем:

# esxcli storage filesystem list

После этого вы можете работать с USB-устройством через папку /vmfs/volumes/NO NAME/. Например, можно установить бандл ESXi с флешки:

# esxcli software vib install -d /vmfs/volumes/NO\ NAME/offline-bundle.zip

3. По завершении работы включаем арбитратор командой:

# /etc/init.d/usbarbitrator start

Интересные новости приходят от Дункана: в VMware vSphere 5.0 Update 2 при переименовании виртуальной машины во время миграции Storage vMotion ее VMDK-диски также переименовываются (раньше это не работало - менялось только имя машины). Но это, почему-то, не включено по умолчанию.

Чтобы это заработало нужно добавить расширенную настройку VMware vCenter. Для этого идем в "Administration" -> "vCenter Server Settings" -> "Advanced Settings" и добавляем параметр:

provisioning.relocate.enableRename со значением true

Итак, титаническая работа была проделана - и диски теперь переименовываются. Однако, почему эта настройка не активирована по умолчанию? Непонятно - бажит наверное...

Для VMware vSphere 5.1 эта штука пока не актуальна (только vSphere 5.0 Update 2), но обещают, что скоро она заработает с очередным апдейтом. Кстати, а почему тут только интерфейс добавления расширенных настроек и нет удаления?

Продолжаем рассказывать о решении для создания отказоустойчивой инфраструктуры хранения виртуальных машин для платформы Hyper-V - StarWind Native SAN. Недавно, кстати, мы писали о том, что появилось бесплатное издание StarWind Native SAN for Hyper-V Free edition с функциями отказоустойчивости хранилищ хост-серверов.

На этот раз предлагаем вашему вниманию документ "Virtualization Reality: Why StarWind Virtual SAN Solutions Deliver Value When Compared to Microsoft", в котором рассмотрены 5 причин, исходя из которых решение StarWind Native SAN имеет преимущества и ценность по сравнению со встроенными средствами Microsoft Hyper-V, такими как Shared Nothing Live Migration, Hyper-V Replica и механизмом кластеризации через SMB 3.0.

Также в документе, помимо всего прочего, рассмотрены архитектуры Scale-Out File Servers, о которой мы уже писали вот тут, и построение кластеров Microsoft на базе дисковых полок SAS JBOD. Как не трудно догадаться, все это хуже, чем решение StarWind Native SAN.

Очень давно мы писали про тип виртуальных дисков Paravirtual SCSI (PVSCSI), который появился в VMware vSphere 4 и был создан для требовательных к ресурсам ввода-вывода нагрузок. На заре своего развития виртуальные диски типа PVSCSI не рекомендовались к использованию в качестве загрузочных, а также имели несколько серьезных багов, но широко тестировались в связи с тем, что показывали большую производительность, чем стандартный LSI SCSI.

Эту статью мы пишем, главным образом, здесь для того, чтобы сказать - уже можно. Виртуальные диски Paravirtual SCSI достаточно стабильно работают в VMware vSphere. В KB 1010398 мы видим матрицу поддержки дисков pvscsi для различных релизов VMware vSphere (обычные и boot-диски):

В VMware vSphere/ESXi 5.1 поддерживается все то, что поддерживалось и в предыдущих версиях платформы.

Что же раньше были за баги с PVSCSI? Смотрим, например, в статье тут, отсылающей нас к KB компании Microsoft. Ошибка существовала для ОС Windows Server 2008 R2 и была критической, а устранена была только в VMware vSphere 5.0 Update 1, о чем есть KB 2004578.

Теперь о том, как поставить диск типа PVSCSI в качестве загрузочного для виртуальной машины на ESXi. Выбираем в vSphere Client контроллер типа VMware Paravirtual :

В настройках виртуальной машины добавляем виртуальный floppy-дисковод и указываем образ дискеты с драйвером PVSCSI, который лежит в папке vmimages->floppies (если там ничего нет, идем сюда):

Дальше при выборе диск для установки Windows указываем драйвер с дискеты:

Дальше ставим все как обычно. Если хочется запихнуть драйвер PVSCSI в кастомизированную ISO-шку, то вам сюда. И да, драйвер на образе дискеты от Windows Server 2008 прекрасно работает на Windows Server 2012, который, в свою очередь, работает на VMware vSphere 5.1.

Компания StarWind Software, производящая продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN & NAS, приглашает на бесплатный вебинар "Increase Operational Efficiency with StarWind!", который проводит Анатолий Вильчинский, системный инженер StarWind Software.

На вебинаре будет рассказано о том, как с помощью решений StarWind можно улучшить эффективность хранения данных виртуальных серверов за счет функций дедупликации, а также функций высокой доступности хранилищ (напомним, что использовать их можно бесплатно).

Вебинар состоится в четверг, 24 января в 19-00 по московскому времени. Регистрируйтесь!

Полгода назад мы писали об особенностях работы технологии VMware Storage vMotion, где касались максимального числа одновременных миграций SVMotion на хранилище VMware vSphere. Там же мы вскользь касались миграций vMotion и упоминали вот эту нашу статью, где рассматривались лимиты одновременных миграций vMotion на серверах и хранилищах.

Теперь, на основе статьи Франка, мы обобщим и актуализуем информацию по миграциям vMotion и Storage vMotion в разных контекстах - на уровне хранилищ, сети и хост-серверов VMware ESX.

Как и в прошлой статье, здесь будем пользоваться понятием стоимости миграции в единицах (cost) и максимального значения костов в тех же единицах (max cost), которое отображает предельно допустимое значение. Сумма костов операций vMotion и SVMotion не должна превышать max cost для соответствующего объекта (datastore, NIC и хост ESXi).

Теперь взглянем на таблички (в них есть не только vMotion, но и SVMotion):

Хост ESXi

Сеть

Хранилище (Datastore)

Читать эти таблички просто - например, для хоста ESXi стоимость миграции vMotion равна 1, а поскольку max cost равно 8, то всего на хост может быть 8 одновременных миграций в конфигурации по умолчанию. Либо допустимы одновременно: 1 миграция SVMotion (4 очка) и 4 штуки vMotion (по одному очку каждая), т.е. суммировать надо по костам: 4+1+1+1+1=8.

Для хранилища (Datastore) также есть ограничения vMotion, поскольку передаются страницы файла подкачки (если он не шаренный между хостами), а также производится передача владения VMX-файлом и другими файлами ВМ на хранилище. Но поскольку влияние это мало, то стоимость vMotion для хранилища всего 1 при максимальной емкости одновременных операций 128 (а вот SVMotion, требующая значительных ресурсов хранилища, "кушает" 16 единиц). Таким образом 1 операция vMotion съест 1 единицу коста, поэтому в этот момент для хранилища будет доступно только 7 миграций SVMotion, т.е. (128-1) div 16 = 7.

Соответственно, редактирование параметра Config Key для соответствующей операции позволяет изменять количество одновременных операций vMotion/SVMotion. Для редактирования параметра Config Key нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:

%ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\

Там нужно вписать новое значение в соответствующую секцию. Например, для параметра maxCostPerEsx41Ds:

< config >
< vpxd >
< ResourceManager >
< MaxCostPerEsx41DS > new value < /MaxCostPerEsx41DS >
< /ResourceManager >
< /vpxd >
< /config >

Если соответствующей секции нет, то ее можно просто добавить. Уменьшать максимальные косты точно можно, а увеличение работает не всегда. То есть гарантированно вы сможете только уменьшить число одновременных миграций vMotion или SVMotion, а вот увеличить - не факт. Ограничение можно делать двумя способами - повышением обычных костов или понижением максимальных костов.

Теперь самое интересное - это динамический параметр max cost для сетевых адаптеров. Как видно из таблицы, его действующее значение зависит от типа сетевого адаптера на хосте - 1G или 10G. Но, на самом деле, и не только от типа. Точнее - от скорости соединения для трафика vMotion между хостами ESXi, которую обнаруживает VMkernel. Таким образом:

• Если VMkernel обнаруживает соединение на скорости 1Gbit/s - Maximum Cost выставляется в значение 4 (это верно и для случая соединения 1G<->10G).
• Если VMkernel обнаруживает соединение на скорости 10Gbit/s - Maximum Cost выставляется в значение 8.
• Если VMkernel обнаруживает соединение на скорости ниже 1Gbit/s - Maximum Cost выставляется в значение 2.

Таким образом, для адаптера возможны либо 2, либо 4, либо 8 одновременных миграций vMotion, в зависимости от действующей скорости соединения. Операция Storage vMotion, как видно из таблицы, костов сети не кушает.

Если ограничение для сети жестче (например, 4 миграции vMotion), чем ограничение для хоста (8 миграций vMotion) - то для машин этого хоста действует ограничение сети.

В прошлой статье про средство резервного копирования и восстановления StarWind Hyper-V Backup Plug-in (опция к StarWind Native SAN for Hyper-V) мы обещали рассказать про такие режимы восстановления как:

• Restore in Sandbox - возможность восстановить ВМ без ее влияния на продуктивную работающую копию (восстановление происходит в изолированное виртуальное окружение)
• Restore from archive - возможность восстановить ВМ напрямую из архива (в случае крайней необходимости)

Restore in Sandbox

Этот режим нужен тогда, когда требуется восстановить ВМ в изолированное окружение и что-нибудь проверить, например, что все данные внутри остались целостными и приложения работают (т.е. архив пригоден для восстановления). Для этого нужно выбрать пункт "Restore in Sandbox" для резервной копии:

Восстановленная и запущенная виртуальная машина будет полностью изолирована от работающей продуктивной копии за счет собственных настроек сетевого взаимодействия и отдельного хранилища.

Вот так это выглядит в консоли Hyper-V Manager:

Restore from archive

Этот режим можно использовать только в экстренных случаях, когда виртуальная машина должна быть восстановлена безотлагательно. Для этого нужно выбрать пункт "Launch VM from Archive" из контекстного меню хранимой резервной копии.

После этого будет выдано предупреждение:

Чекбокс перед восстановлением заставляют поставить потому, что такой тип восстановления приведет к тому, что все инкременты данной резервной копии будут потеряны (т.е. останется только полная резервная копия последнего состояния), поскольку нужно запустить виртуальную машину, используя образ ВМ из архива.

Поэтому, если есть возможность, следует использовать варианты восстановления "Restore Original VM" или "Restore in Sandbox"

Напомним также, что у StarWind есть плагин для резервного копирования виртуальных машин и на платформе VMware vSphere - VMware Backup Plug-in.

На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):

• ESX 3.0.1
• ESX 3.5

Итак, для первого тестирования использовалась следующая конфигурация:

В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.

Масштабируемость производительности под нагрузкой (OPM - это orders per minute):

Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):

Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:

Теперь обратимся ко второму исследованию. Там использовалась следующая тестовая конфигурация, выдающая 1 миллион IOPS на тестах:

Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers

Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):

Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).

Второй тест - 60% операций чтения и 40% операций записи:

Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.

Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.

Мы уже много писали про продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, в том числе про экономическую эффективность решения и его новые возможности. Многие знают, что у StarWind есть хорошая подборка материалов по настройке и эксплуатации данного продукта.

Сегодня мы хотим обратить ваше внимание на документ "StarWind iSCSI SAN & NAS: Multipathing", в котором детально и по шагам рассказывается о настройке механизма доступа по нескольким путям (MPIO) при использовании сервера хранилищ StarWind iSCSI SAN. В руководстве рассматривается настройка серверов на базе следующей схемы подключения:

В документе описаны способы настройки серверов как на платформе Windows Server 2008, так и Windows Server 2012.

Duncan и Frank, известные своими изысканиями в сфере механизмов отказоустойчивости (HA) и балансировки нагрузки (DRS) в виртуальной инфраструктуре VMware vSphere, опубликовали пару интересных материалов, касающихся настройки среды vCloud Director и механизма Storage DRS.

Как вы знаете, в настройках кластера хранилищ (Datastore Cluster) есть галка, которая определяет, будут ли виртуальные диски VMDK машин обязательно находиться на одном хранилище (Datastore) при миграции средствами механизма Storage DRS:

Надо отметить, что галка Keep VMDKs together by default - это не совсем простая для понимания галка. Если ее не поставить, то действовать будет обратное - диски виртуальной машины будут обязательно размещаться на разных хранилищах. Это, по заверениям блоггеров, даст больше гибкости в использовании механизма SDRS в среде vCloud Director при перемещении виртуальных машин между хранилищами, что даст больше преимуществ в динамически балансирующейся среде (особенно для "тонких" дисков). Соответственно, по умолчанию галка Keep VMDKs together by default должна быть выключена.

Мы уже писали о том, что средствами StarWind iSCSI SAN 6.0 можно создать трехузловой отказоустойчивый кластер хранилищ для виртуальных машин VMware vSphere (+ про экономический эффект). А на днях вышел документ "StarWind iSCSI SAN & NAS: Configuring 3-node HA Shared Storage for vSphere", описывающий настройку целевой архитектуры такого кластера:

В документе подробно описаны процессы создания HA-устройств, настройка каналов синхронизации, а также необходимые конфигурации серверов VMware ESXi.